Surely this has all the same problems as OSC 7 (#3158)? Realistically it's most likely going to be used in a WSL shell, so the file path will be in the WSL filesystem, and thus won't be understood by ShellExecute. Until we have a way to appropriately convert file paths based on the active shell, this just doesn't seem practical.

Also, using ShellExecute on a file url seems risky from a security point of view. If the file path points to an executable then that executable is going to be run. I'm not sure how much damage could be done that way, but I wouldn't feel comfortable knowing an attacker could run any executable on my system just by tricking me into clicking somewhere.

From security point of view, I expect Windows Security or third party vendors for A/V, FW, HIDS/HIPS to handle the protection. Additionally there's a ransomware setting that basically denies all executables from doing anything to protected parts of the filesystem. Its not completely up to WT to handle the security here. People want this functionality and should understand the security implications. If there's a more secure way for files to get opened including executables then great. Just as long as it's understood we're inheriting most of the security from Windows.

#7420 should land before this, so that people can see what they are going to be clicking on.

The Uri class has a property called Extension() which in the case of the file scheme, we can use to get the file extension.

So perhaps one way of solving this would be by having a dialog that pops up when a user clicks a link with the .exe extension - the dialog would inform them that the link is an executable (the URI will be provided too) and give them the option of opening the link anyway or canceling the operation. We could also have a setting to prevent such dialogs from appearing (in which case the link will just open).

Thoughts?

EDIT: Nevermind, there are too many types of executables to account for

I agree with this. Dialogs by default with a setting to disable the dialog and simply run the executable.

technically we also have to consider scripts as well. Malicious programs written in go, python, ruby, etc can still run if the programming language is installed

No.

@j4james Alright, I finally get to come back with a bit of an answer to this.

Also, using ShellExecute on a file url seems risky from a security point of view.

We chatted with the defender/application security folks about this. At the end of the day, ShellExecute ends up using the same reputation services as the rest of Windows. Defender/ATM/"Sense" gets a chance to intervene if the executable is unsigned or untrustworthy.

Looking at it all-up:

• this doesn't let a would-be attacker specify command-line arguments (ala "cmd.exe /s /c do_a_bad_thing") (using somebody else's reputation to cause mayhem)
• Links require affirmative (Ctrl+click) action to activate, and I will staunchly refuse to add support for opening one without a modifier key
• For links that the user has vetted:
  • A local application that can overwrite a linked region with another link is running at-or-above user permission and can just do_the_bad_thing() (or the reputation service kicks in)
  • A remote application that can overwrite a linked region either...
    1. can manipulate a UNC path and replace an executable (network permission required; reputation service kicks in)
    2. can make a user launch an otherwise-acquired local executable (reputation service kicks in)
• ShellExecute de-elevates because it bounces a launch request off the shell

I'm less concerned about the security aspect of this feature.

Now- for WSL paths. "Works predictably for 15% of applications" (h/t to PhMajerus' AXSH, and other on-Windows requestors) is better in so many ways than "Works for 0% of applications", in my estimation. Incremental progress 😄 while we work on features that'll make it even more broadly applicable.

I'm inclined to call in favor of merging this.

We chatted with the defender/application security folks about this.

I'm still not completely comfortable with this myself, but if your security folk are satisfied that it's not going to be a problem, then that is at least some reassurance. For those of us that are more paranoid, it might be nice to have an option to disable some or all of the hyperlink functionality, but that could always be a follow-up PR.

Do we have a separate issue for the auto-hyperlinking of plain file paths, for example D:\, just like we did for http & https links in #7691 ? This one is admittedly harder but also quite useful.

I observed an interesting behavior in iTerm2 (I just really used iTerm2 a lot back in the days as iOS developer): it actually detects if the file path is legal before hyperlinking it. For example, if the path is /Library/Apple, you can ctrl+click the path to open it in Finder. But the if the path is /Library/Appl, there's no hyperlink at all. I haven't tested how ssh works, though.

Inspired by #8166 (comment), we can also make the result of ls clickable if the CWD is provided. This is also possible in iTerm2. I'm not sure which sequence or technology it uses to detect the CWD, though. Anyway, with OSC9;9 recently added, this is also possible in WT.

Misspellings found, please review:

• hostnames

pushd $(git rev-parse --show-toplevel)
perl -e '
my @expect_files=qw('".github/actions/spelling/expect/alphabet.txt
.github/actions/spelling/expect/expect.txt
.github/actions/spelling/expect/web.txt"');
@ARGV=@expect_files;
my @stale=qw('"aspnet boostorg COINIT dahall fde fea fmtlib isocpp mintty NVDA pinam QOL remoting unte vcrt what3words xamarin "');
my $re=join "|", @stale;
my $suffix=".".time();
my $previous="";
sub maybe_unlink { unlink($_[0]) if $_[0]; }
while (<>) {
  if ($ARGV ne $old_argv) { maybe_unlink($previous); $previous="$ARGV$suffix"; rename($ARGV, $previous); open(ARGV_OUT, ">$ARGV"); select(ARGV_OUT); $old_argv = $ARGV; }
  next if /^(?:$re)(?:(?:\r|\n)*$| .*)/; print;
}; maybe_unlink($previous);'
perl -e '
my $new_expect_file=".github/actions/spelling/expect/c07553cb57e1b5c709ff90a4e0ada7052d04d9a3.txt";
use File::Path qw(make_path);
make_path ".github/actions/spelling/expect";
open FILE, q{<}, $new_expect_file; chomp(my @words = <FILE>); close FILE;
my @add=qw('"coinit hostnames Remoting "');
my %items; @items{@words} = @words x (1); @items{@add} = @add x (1);
@words = sort {lc($a) cmp lc($b)} keys %items;
open FILE, q{>}, $new_expect_file; for my $word (@words) { print FILE "$word\n" if $word =~ /\w/; };
close FILE;'
popd

I'm going to merge this with no backport to get Preview into the hands of more folks who can help us evaluate whether this is a risk and if we should back it out or restrict it further. I do, though, hear & value James' concerns about autoexecuting a script on click(!)

🎉Windows Terminal Preview v1.7.572.0 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Store Download